From nakoruru@usagi.jrd.dec-j.co.jp Mon Oct 24 22:58 GMT 1994
Return-Path: <nakoruru@usagi.jrd.dec-j.co.jp>
Received: from bgate.lut.ac.uk by hpb.lut.ac.uk (15.11/SMI-4.1)
        id AA28376; Mon, 24 Oct 94 22:58:22 gmt
Received: from jnet-gw-1.dec-j.co.jp by mailhost.lut.ac.uk with SMTP (PP) 
          id <25090-0@mailhost.lut.ac.uk>; Mon, 24 Oct 1994 22:58:08 +0000
Received: by jnet-gw-1.dec-j.co.jp (8.6.9/JNET-GW-940327.1); id HAA27580;
          Tue, 25 Oct 1994 07:49:57 +0900
Received: from usagi.jrd.dec.com by garfield.jrd.dec.com (8.6.9/JULT-4.4-gar) 
          id HAA06799; Tue, 25 Oct 1994 07:51:10 +0900
Received: by usagi.jrd.dec.com (8.6.9/JULT-usagi-4.X) id HAA10354;
          Tue, 25 Oct 1994 07:55:24 +0900
Received: from jnet-gw-1.dec-j.co.jp 
          by usagi.jrd.dec.com (8.6.9/JULT-usagi-4.X) id HAA10351;
          Tue, 25 Oct 1994 07:55:23 +0900
From: a4el@jupiter.sun.csd.unb.ca
Received: by jnet-gw-1.dec-j.co.jp (8.6.9/JNET-GW-940327.1); id HAA27566;
          Tue, 25 Oct 1994 07:49:24 +0900
Received: from jupiter.sun.csd.unb.ca by unb.ca (8.6.9/941012-15:50) 
          id TAA19607; Mon, 24 Oct 1994 19:47:14 -0300
Received: by jupiter.sun.csd.unb.ca (4.1/SMI-4.1-941013-14:25) id AA27277;
          Mon, 24 Oct 94 19:47:13 ADT
Date: Mon, 24 Oct 94 19:47:13 ADT
Message-Id: <9410242247.AA27277@jupiter.sun.csd.unb.ca>
To: kiss@usagi.jrd.dec.com
Reply-To: kiss@usagi.jrd.dec-j.co.jp
Status: RO



I'm posting to this mailing list to talk about a plan, or a project, that
I thought of while fiddling with some KISS data sets. Please excuse all
these "^M" signs.. I wrote this at home and transferred it here to UNIX 
from DOS.

While playing with them, two thoughts crossed my mind; firstly, there
seemed to be a lot of redundancy concerning clothes in these sets. 
Every set has its own school gym uniform, its sailor suit, its bunny
suit, and so on; a good data set has a set of 'must-haves' that the
artist has to take the time to draw.  And all the redrawing seemed
to take up needless memory/storage space to me.

Secondly, the cels don't move or change in perspective.  So if you
want another shot of the same character, you need to draw a new body
and probably a whole new set of clothing to fit that new angle of
the character; or you hope that another author's created their own
data set of that character.  Which again seems to be a waste.

These thoughts were in my head as I marched around uptown one night.
Then I started playing the new SNK arcade game, "King of Fighters '94"
Looking at the characters, I was impressed by how consistently they
were drawn, and how they kept their expressiveness; I had heard that
SNK had used polygons as a drawing tool, and they did a good job of
merging it with actual art.

So from these three sources, came my idea.

FUKU
----
Figurine Using Kisekae Utility
------------------------------

After seeing 3d plane games and 3d Virtua fighters, 3d DOOM games, and
so forth, why not attempt a 3d Kisekae utility?  Here's a rundown of
the ideas I had for interface and file formats.


.CHA Character file.  A 3d description of the character.  It would contain:
     -The description of the porportions of the character's head, limbs,
      torso, etc. Now. FUKU would be specialized for drawing humanoid forms;
      so the engine would only need information of sizes and shapes. For
      example; "The legs are especially thin and long for this character."
      "The character's toes are undefined." With some research, enough
      parameters could be found to conceivably morph a generic human form
      into a character of any anatomical style by finding out what the
      particulars of that style are.  Also thrown in would be hair/skin
      color, etc.
     -Facial expression list.  While in FUKU a large portion of time would
      be spent rotating limbs and joints around, rotating mouths and eyes
      would be a bit tedious. So, for each character, a series of texture
      maps would be supplied for the face (not full face textures; eyes
      and mouths would be best seperate.)
     -Default clothing.  It would be jumping ahead of the game if a 
      character popped up naked when you loaded him/her. ;) This is a list
      of clothing resources that the program loads and places on the 
      character when the character is loaded.

.RES Resource file.  3d descriptions of clothing and props.
     -An item of clothing is a 3d description of itself in terms of its
      surfaces.
     -As well as its description, each clothpiece would have a menu of
      options concerning its placement..
      ON. This cloth-option puts the clothing directly on the character in
          its natural place (this saves the user the effort of trying
          to manipulate the cloth on the user.)  When the character is 
          moved, the clothing is 'pushed along' with the player; certain
          portions of the clothing are marked stiff or not-stiff (see below
          for what I mean.)
      ON-OTHER. The clothing is still on the person, but in a special 
          form.  For instance, a jacket with the jacket's back flared
          upwards; most of the jacket moves with the person, but the
          jacket's back is 'stiff'.  It will always remain flared at
          an angle with the character's back.
      OTHER. The clothing is not on the character, but is in the scene,
          either crumpled, floating, and so forth.. each piece of clothing
          would have its own set of options beyond ON.  For instance,
          a scarf might have several ON options (wrapped round the neck,
          wrapped round the waist) and a few more options for being
          crumpled on the ground, layed snake-like, etc.

     -Clothing, when on, would be defined in terms relative to the 
      character; thus, a shirt's sleeve might end "halfway between the
      elbow and the wrist" and have a radius "1 or 2 units greater than
      the radius of the arm at the wrist point and 10 or 12 units g.t.
      t.r.of the arm near the shoulder", to create a poofy sleeve with
      a snug wrist.  Note that this means all clothes have to be 
      associated with a character when loaded, even if the clothing
      is just going to be part of the scenery.
     -Props are simply 3d objects make of boxes, etc. and painted to
      look nice. :) They have absolute dimensions rather than relative
      ones, and don't have any wearing-options.
      
.POS Pose file.  A description of limb placements for a character, to
     make him/her shrug, make a V-sign, etc.

.PAK Package file. This is most like .CNF files for KISS.  They consist
     of a series of field descriptions (Field: think sets 0-9 in KISS.)
     and a list of .RES,.CHA, and .POS files to load and set up for
     each.  A typical archive for FUKU would have a few characters, 
     their trademark clothing, some more items, and a .PAK file to 
     show off with.

.KAT Kata file. This is like a package file, but a bit different. A kata
     file is used to show off animations or stories. It can have the 
     following modes:

     Animation: Load this, and the .KAT sets up the fields out of sight,
     screen capturing each 'frame' into a file.  The show is then played
     back once the calculations are finished.
     Story: The .KAT file sets up fields like a .PAK file; not the
     working fields available, but its own.  It then lets you page through
     the fields one by one; optionally a short text file is also present
     to let you understand what's happening.


.PCX Background files. :) Certain pictures can be loaded up to use as
     static backgrounds for the figurine characters. These files can
     be mentioned in .KAT and .PAK files.

The interface

 FUKU will have a viewing screen, a series of buttons from 0 to 9
 (working fields, click to change) and a menu.

 LOAD    MANIPULATE   CHECK   SAVE  MISC EXIT

 Now, there is a difference that should be noted; an item can be in 
 memory but not in specific fields.  The program starts with nothing
 in memory or fields.

 LOAD loads things into memory; not in fields.  You can load
 characters, clothing (only if there is a character to associate itself
 to), props, poses (again, characters) or packages/katas, or backgrounds.

 CHECK lets you look at what items are in memory, and which fields if
 any each item is in.  You can also erase items from this list.

 MANIPULATE has a submenu of Change, Remove, Dismiss.  Manipulate only
 has the scope of the current field being worked with, so when you
 choose an option, only the items in that field will be listed.

 Dismiss removes the item from the field.
 Remove erases the item from the field and memory (thus, all fields.)
 Change calls up submenus depending on the object you pick.

 Clothing: Reassociate (change owner of the clothing, refitting it.)
           Change-Option (change the clothing option; changing it
           to a non-ON option removes the clothing from the wearer
           if it is currently ON.)
           Translate XYZ Rotate XYZ. (self-explanatory.)
 Prop:     Translate XYZ Rotate XYZ  (" " " " " " " " ")
           Glue (Hitch an object to a point on a character. The prop
           now translates and rotates along with that point.)
           Unglue (Only if glued.)
 Character:Translate XYZ Rotate XYZ
           Bend (You are given a list of joints to choose from.. this
           is probably the most tedious part of using FUKU, but
           a nice interface would help.)
           Face (Change the character's list of expressions.)

 SAVE allows you to save your work.

 Save Character allows you to save a character and make what the character
 is currently wearing their Default Clothing.

 Save as .PAK allows you to save the information in the fields and memory
 as a PAK file.

 Save as .KAT allows you to do likewise; whether as animation or story
 (you'd be prompted for text.) If your kata is longer than 10 fields, 
 you can opt to Append to KAT files with your fresh set of 10 more
 fields. You are also prompted for field ranges, for shorter katas.

 Save as .POS allows you to select a character and save that character's
 pose (bodily pose only) in a file.


 MISC covers changing camera angles (Move camera to some preset positions)
 and light sourcing (see below)

 NOTE ON HAIR

 I think a character's hair would be best as part of Default Clothing,
 with wearing-options and such, for best flexibility.

 NOTE ON RENDERING

 Rendering can be slow, depending on how complex we want to make it.
 But since this is a kisekae program, we do want the characters to
 look good i.e. rounded curves and so forth.

 Here is my goal; I believe a good aiming point is to make it as complex
 and good-looking as the characters in King of Fighters '94.  They look
 fairly attractive, and if the characters are slightly larger on the
 screen, rendering wouldn't be too much of a hassle.

 Texture mapping: To get the clothing to look like in the game, TM'ing
 might be a good idea to include in designing new clothing items.
 I'm just saying it to remember for in the future.

 Light: Light causes shading and highlights. All right. For speed's sake,
 we should cheat on light; say it can come from Front,Back,L.Side,R.Side,
 Below, or Above, and use short cuts from there. An example of a short
 cut.. notice in KISS drawings how a leg tends to be bright in the 
 leg's centre and regularly graded darker near the edge? That wouldn't
 require light-bouncing mathematics to duplicate. ;) Figure out each
 surface on the screen in a 2d sense and take it from there. As for
 color pallettes.. say that 72 colors make up FUKU colors (Crayola
 box of crayons + 8 extra skin tones. :) ) and other pallette colors
 are defined as needed to handle shading.

NOTE ON USERS

  In KISS, users and designers were fairly close to each other; if you
  knew how to draw, converting PCX files to cels was fairly trivial, as
  was designing a CNF file.

  In FUKU, obviously designers will have to know what they are doing,
  unless a very friendly designing application is written.  Users,  
  however, can have more to do than KISS in a creative sense.  While
  pure users of KISS can't output anything creative, interesting
  juxtapositions of things can be stored on PAK or KAT files and 
  themselves distributed.                


 --------------

 Anyhow, that's the ideas I have; I may have more in my head, but that's
 all I was able to retrieve right now.  

 Now, I don't have the programming skill or knowledge of 3-d techniques
 to implement this.  This bummed me, but then I realized something:
 just because I don't know how to do it myself doesn't mean I can't
 see it done.  Maybe there are people out there who do know 3d who are
 looking for the chance to work on a fun and worthwile project..

 I'm looking for programming volunteers, first here on this mailing list,
 then out in other places.  I can't help you myself too much; all I can
 do is provide organization, a clear defenition of the project, and
 provide programming of the interface once things begin to take shape.

 So, this is my great idea.  Is anyone interested?

 -Aphoriel/Kinsman
 Sean Givan

 P.s. Anyone know TomWoof's address offhand? He's on alt.games.sf2 from
 time to time distributing raytraced images of figures of Chun Li and
 Cammy from Street Fighter II.  He could probably be a *big* help to us..
